1. Field of the Invention
The present invention is directed to a method and apparatus for inserting mediation metadata into a Simple Object Access Protocol (SOAP) message based on existing Web service client engine.
2. Background Description
Web Services (WS) are being considered an excellent technology to achieve business integration. Many companies are putting effort on integrating internal and external application and resources by Web Services.
Web Services involve a family of related protocols to describe, deliver, and interact with services. This family can be further subdivided into groupings based on common functions and uses. The first group handles the issues of messaging, interface description, addressing and delivery. The most well-known is the messaging protocol known as Simple Object Access Protocol (SOAP). This protocol encodes messages so they can be delivered over the network using a transport protocol such as Hypertext Transfer Protocol (HTTP), Internet Inter-Orb Protocol (IIOP), Simple Mail Transfer Protocol (SMTP), or others. The Web Services Description Language (WSDL) is represented as a series of eXtensible Markup Language (XML) statements that constitute the definition for the interfaces of each service. The Universal Description, Discovery and Integration (UDDI) protocol defines a registry and associated protocols for locating and accessing services. Web Service Policy (WS-Policy) provides a general purpose model and syntax to describe and communicate the policies of a Web service.
Although there are many specifications on Web Services, there are still many problems to be solved when putting Web Services into practice. Web Services are published for consumer invocation. Different consumers have different requirements, both functional and non-functional. But there is no way for a consumer to negotiate with a Web Service to customize the Web Service at runtime. The interaction between service provider and service consumer is SOAP message exchange. Customization of a Web service is equal to customizing SOAP message structure and content. Current Web Services engines can not provide such capabilities. Some examples are described below.
The SOAP body can not be customized. If a consumer and a service have different data schema, transformation on the SOAP body must be performed between the consumer and the service. For example, a travel agent application requests a train list by invoking a train query service. The query service has an operation named “GetAllTrains”, whose return type is “AllTrains”. But the travel agent uses a Train List, which is different from a Ticket. So a data mapping should be put into the server side or the client side. Under most conditions, the server would not provide an additional method or mapping handler for the individual consumer. That means the consumer should adapt itself to the service, or the mapping work is always done a the consumer side. This solution is not good enough under some conditions, such as when the consumer has a poor computation resource, or the consumer does not know how to perform Such a transformation.
The message content can not be filtered. A consumer can not selectively retrieve an invocation result. For example, “AllTrains” will be returned by the service, but “AllTrains” is a large record, which contains detailed information of each train, while the consumer only needs the train number of each train. Transferring unnecessary data will not only cost network resources, but also increase overhead on data serialization and deserialization.
The security policy can not be changed according to the customer's requirements. The security policy is claimed using WS-SecurityPolicy. It could be retrieved by the consumer using WS-MetadataExchange at runtime or from the WSDL document which has the WS-Policy attached at design time. Then the consumer could construct a SOAP request following the security policy. This mechanism lacks the flexibility of constructing the SOAP invocation message. First of all, the service can not provide multiple policies so the client can not select a policy. All consumers must share the same security policy, which is configured statically. On the other hand, the client can not change the policy. For example, a train query service does not define the security policy, but an agent wants the result message to be encrypted. It is impossible to achieve such encryption without configuring the service.
In current solutions, the service provider needs to take great effort in changing the security policy, adding a transformation handler and employing a filtering method for different consumers.
Some solutions have been proposed to address some of these issues. U.S. Patent Application Publication No. 20030217044 A1 provides a solution to automate a method signature adaptation for dynamic web service invocation. It adds a MetaWSDL to each service. MetaWSDL is an XML presentation to describe a MetaObject. By adding this semantic information, different input messages could be transformed to messages conforming to WSDL of service. This method requires changes at the client side, at the UDDI server and at the service provider side. The method could only change parameter types of Web service methods. Security policy changing and SOAP response filtering can not be performed. Moreover, the method presented in U.S. Patent Application Publication No. 20030217044 A1 does not use the SOAP header to carry the MetaWSDL, which is grouped with a corresponding WSDL document in a WSIL (Web Services Inspection Language) document.
A Web service gateway provides the ability to transmit a SOAP message. It acts as a mediator between the service provider and the service consumer. The main value of the gateway is to have a central control point on distributed services. Transformation and filtering could be done only by adding handlers which need additional development work.